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Abstract  - This  paper  summarizes  the  first  twenty  years  of 
concurrent  programming  and  identifies  the  major  development 
O phases  as  an  initial  .hardware  challenge  followed  by  a software 
^ crisis,  a conceptual  innovation,  and  language  development  which 
j y in  turn  led  to  formal  understanding  and  hardware  refinement, 

I Li  The  paper  draws  a parallel  between  this  development  and  the 
•1^  present  challenge  of  distributed  computing. 
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I.  INTRODUCTION 


This  keynota  address  summarizes  the  highlights  of  the  first 
twenty  years  of  concurrent  programming  (1960-80)  and  takes  a look 
at  the  next  twenty  years  (1960-2000). 

A concurrent  program  is  one  that  enables  a computer  to  do  many 
things  simultaneously.  Concurrent  programming  is  used  to 
increase  computer  efficiency  and  to  cope  with  environments  in 
which  many  things  need  attention  at  the  same  time.  Although 
there  are  good  economic  and  conceptual  reasons  for  being  interested 
in  concurrent  programs  there  are  major  difficulties  in  making  these 
programs  reliable. 

The  slightest  programming  mistake  can  make  a concurrent  program 
behave  in  an  irreproducible,  erratic  manner  that  makes  program 
tasting  impcssibla*  Ths  following  describes  how  this  problem  was 
gradually  solved  by  software  engineers  and  computer  scientists. 

This  development  is  seen  as  an  initial  hardware  challenge 
followed  by  a software  crisis,  a conceptual  innovation,  and 
language  development  which  in  turn  led  to  formal  understanding 
and  hardware  refinement.  The  paper  draws  a parallel  between  this 
evolution  of  ideas  and  the  present  challenge  of  distributed 
computing. 


II.  THE  DEVELOPWENT  CYCLE 


Uhen  you  look  at  concurrent  programming  on  a time-scale  of 
decades  you  will  see  that  it  went  through  several  stages  of 
development  each  lasting  about  5 years: 

Hardware  challenge  (1955  - 60) 

Software  crisis  (1960  - 65) 

Conceptual  innovation  (1965  - 70) 

Language  development  (1970  - 75) 

Formal  understanding  (1975  - ) 

Hardware  refinement  (1980  - ) 


At  the  beginning  of  this  period  neui  hardware  developments  make 
concurrent  programming  both  possible  and  essential.  As 
programmers  experiment  with  this  new  idea  they  are  gradually  led 
to  the  development  of  extremely  complicated  systems  without  much 
of  a conceptual  basis  to  rely  on.  Not  too  surprisingly  these 
systems  soon  become  so  unreliable  that  the  phrase  "software 
crisis"  is  coined  by  their  designers.  By  then  the  importance  of 
the  problem  is  recognized  by  computer  scientists  who  start  a 
search  for  abstract  concepts  that  will  simplify  the  understanding 
of  cnncurrent  programs.  Once  the  essence  of  the  problem  is 
understood  a notation  is  invented  for  the  basic  concepts  and  it 
now  becomes  possible  to  define  them  so  precisely  that  they  can  be 
incorporated  into  new  programming  languages.  This  language  notation 
in  turn  enables  theoreticians  to  develop  a more  formal  understanding 
of  the  problem.  At  the  same  time,  the  new  language  concepts 
inspire  innovative  computer  designers. 

At  this  point  (if  not  sooner)  new  hardware  possibilities 
start  another  development  cycle.  One  must  indeed  agree  with  Alan 
Perils  that  "hardware  drives  the  field."  but  one  must  also  add  that 
"abstractions  make  it  manageable." 

Ule  will  look  at  each  of  the  stages  that  concurrent  programming 
went  through  and  see  what  the  next  challenge  is  likely  to  be. 

III.  THE  HARDWARE  CHALLENGE 

Around  1955  computer  architecture  changed  drastically  with  the 
invention  of  larce  .maonetic  core-  stores  and  asynchronously 
operating  peripheral  devices.  It  now  became  possible  to  write 
large  programs  cf  10.000  • 1.CQQ.QCQ  machine  instructions.  At 
the  same  time  interrupts  made  it  possible  to  srite  concurrent 
programs  that  could  switch  a fast  processor  among  its  much  slower 
peripheral  devices  and  make  them  operate  simultaneously. 

The  intellectual  challenge  of  this  tachnciogical  revolution 
was  formidable.  For  the  first  time  programs  became  too  large  to 
be  understood  completely  by  a single  programmer.  In  response  to 
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this  challange  computar  programmars  Inventad  the  first  abstract 
programming  languages,  Fortran  and  AlgolSQ,  and  made  their 
compllars  soma  of  the  best  understood  and  most  reliable  system 
programs  «e  knoui*  All  this  happened  in  less  than  10  years.  A 
most  impressive  achievement  j[lj , 

The  capabilities  for  simultaneous  execution  of  several  tasks 
on  one  computer  did,  however,  create  a serious  problem  that  took 
much  longer  to  solve:  Programming  errors  could  now  cause  a 
concurrent  program  to  behave  in  an  erratic,  time-dependent 
manmir.  These  errors  were  extremely  difficult  to  find  since  their 
affect  varied  from  one  execution  to  the  next  even  when  the  input 
data  remained  the  same.  It  has  taken  twenty  years  to  cope  with 
this  problem  of  concurrency. 

If  you  look  at  ccmputers  from  a programmer's  point  of  view 
the  main  problem  is  to  master  the  complexity  of  the  hardware 
innovations  that  were  introduced  two  decades  age.  By  comparison 
mini-  and  microcomputers  are  not  revolutionary  at  all.  Their 
economic  impact  and  the  numerous  possibilities  for  new 
applications  are  far  reaching.  But  they  have  not,  so  far,  posed 
new  programming  problems  of  the  same  difficulty  (thank  heaven). 

IV.  THE  SOFTUIARE  CRISIS 

The  slowness  of  peripheral  devices  made  asynchronous  operation 
essential  for  efficient  computer  operation.  But  the  pitfalls  of 
concurrency  made  it  equally  important  to  present  the  user  with  a 
simple,  sequential  interface  to  the  machine.  The  new  system 
programs  that  were  supposed  to  make  a concurrent  computer  system 
both  simple,  reliable,  and  efficient  wers  called  ocerat ino 
systems. 

Some  of  the  early  batch  processing  systems,  such  as  Atlas  (1561 ) 
and  Exec  II  (1962),  were  both  efficient  and  simple.  But  they  were 
not  entirely  reliable.  In  looking  tack  Sill  Lynch  observed  that 
"several  problems  remained  unsolved  with  the  Exec  II  operating 
system  and  had  to  be  avoided  by  one  ad  hoc  means  or  another*.  The 
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problem  of  deadlocks  was  not  at  all  understood  in  1962  uihen  the 
system  was  designed.  As  a result  several  annoying  deadlocks  were 
programmed  into  the  system"  |_23  • 

The  early  time-sharing  systems,  such  as  CTSS  (1962)  and  SDC 
Q-32  (1964)  were  also  of  modest  size. 

Now,  when  faced  with  a new  idea  programmers  have  an  ix'resistable 
urge  to  push  it  to  its  natural  limits  and  then  beyond.  The  next 
generation  of  operating  systems  were  complex  beyond  human 
comprehension.  The  Wultics  system  (l965)  required  200  man-years 
of  development  effort,  and  0S360  (1966)  a staggering  5000  man- 
years,  Because  of  its  size  0S360  became  quite  unreliable.  In  1969 
Hopkins  said  this:  "Ule  face  a fantastic  problem  in  big  systems. 

For  instance,  in  CS36Q  we  have  about  1000  errors  in  each  release 
and  this  number  seems  to  be  reasonably  constant"  ^3] , 

At  this  point  it  had  become  common  for  large  operating  systems 
to  fail  daily  and  it  was  doubtful  whether  they  ware  achieving 
their  original  aim  of  ensuring  efficient,  reliable  computer 
operation.  There  was  a clear  feeling  at  this  point  that  it  was 
just  not  possible  to  design  these  large  programs  without  some 
conceptual  basis  that  would  make  them  more  undsrstandabls. 

The  importance  (and  the  failure)  of  operating  systems  had  by 
now  become  clear  to  computer  scientists  who,  like  all  other 
computer  users,,  were  forced  to  depend  on  these  systems  in  their 
own  computing  centers.  And  so  the  search  for  abstractions  began, 

V.  THE  CONCEPTUAL  INNOVATION 

In  looking  back  at  this  devslcpment  it  is  clear  that  it  was  a 
search  for  concepts  that  would  make  it  possible  to  divide  a 
concurrent  program  into  smaller  asynchronous  modules  with 
time-indeoendant  behavior. 

The  idea  of  dividing  a concurrent  program  into  seouential 
orccossgs  that  are  executed  asynchronously  was  by  far  the  nest 


important  innovation.  This  idea  and  its  implementation  was 
pioneered  at  niT  in  the  CTSS  project  [4J , 

A process  is  a program  module  that  consists  of  a data 
structure  and  a sequence  of  statements  that  operates  on  it. 

If  each  process  only  operates  on  its  own  data  then  it  will 
behave  in  a completely  predictable  manner  each  time  it  is 
executed  with  the  same  data.  Hardware  protection  mechanisms  can 
prevent  processes  from  referring  to  each  other's  data  structures 
by  mistake. 

It  now  became,  possible  to  perform  unrelated  tasks  simultaneous- 
ly without  time-dependent  interference.  However,  if  processes 
share  computer  resources  or  cooperate  on  common  tasks  then  they 
must  also  be  able  to  share  data  in  a controlled  manner.  During 
the  lata  sixties  the  main  focus  was  the  invention  of  safe  methods 
for  synchroniring  processes  which  share  data. 

Dijkstra's  THE  system  (19(33)  is  the  milestone  of  this  era 
[^5  « tJ  , It  introduced  most  of  the  concepts  on  which  our  present 
understanding  of  concurrent  programming  rests.  Dijkstra  noticed 
that  ail  communication  among  processes  bcils  down  to  performing 
operations  on  common  data.  But  if  several  processes  operate 
simultaneously  on  the  same  variables  at  unpredictable  speeds  the 
result  will  be  unpredictable  since  none  of  the  processes  has  any 
way  of  knowing  what  the.  others  are  doing  to  the  variables. 
Dijkstra  therefore  concluded  that  it  is  essential  to  perform 
the  operations  on  common  variables  strictly  one  at  a time.  If 
one  process  is  operating  on  common  variables  then  the  machine 
must  delay  further  operations  on  the  same  variables  until  the 
present  operation  is  finished.  Dijkstra  introduced  the  name 
critical  raoion  for  operations  on  common  variables  which  take 
place  ore  at  a time. 

Critical  regions  only  prevent  competing  processes  from  using 
common  variables  simultaneously.  But  they  do  not  help  in 
transmiiting  data  corroctly  from  cne  process  to  another.  In 
looking  at  the  problem  of  process  communication,  Dijkstra  began 


by  studying  the  simplast  possible  case  In  uihlch  timing  signals 
are  sent  from  one  process  to  another.  For  this  purpose  he 
Invented  a data  type,  called  a semaphore. 

A signal  operation  permits  a process  to  transmit  a timing 
signal  through  a semaphore  variable  to  another  process  luhlch 
receives  the  signal  by  performing  a uialt  operation.  In  a 
concurrent  system,  the  programmer  cannot  predict  the  relative 
speeds  of  asynchronous  processes.  It  Is  therefore  impossible  to 
knout  ^•'ihether  one  process  uiill  try  to  send  a signal  before  another 
process  is  ready  to  rscelve  it  (or  vice  versa).  Dijkstra  removed 
this  problsm  by  defining  the  semaphore  operations  in  such  a way 
that  it  doesn't  matter  in  uihich  order  they  are  initiated..  If  a 
process  tries  to  receive  a timing  signal  before  it  is  available, 
the  uait  operation  uiill  simply  delay  the  process  until  another 
process  sends  the  noxt  signal.  Conversely,  if  signals  tamporarily 
are  being  sent  faster  than  they  can  be  received,  they  will  simply 
be  stored  in  the  semaphore  variable  until  they  are  needed. 

The  eammutativitv  cf  serraphore  opsratlons  made  process 
synchronization  time-independent . Dijkstra  then  wont  on  to  show 
hon  critical  regions  and  message  buffers  can  be  implemented  by 
means  of  semaphores. 

Dijkstra' a multiprogramming  system  also  illustrated  the 
conceptual  clarity  of  hierarchical  structure.  His  system 
eensistad  of  several  program  layers  uihich  gradually  transform  the 
physical  machine  into  a more  pleasant  abstract  machine  that 
simulates  several  processes  ehich  share  a large,  homogenous  store 
and  several  virtual  devices.  These  program  layers  can  be  designed 
and  studied  one  at  a time. 

His  co-utorker  Habermann  shouted  that  a hierarchical  ordering  of 
resource  requests  and  message  communication  also  can  prevent 
deadlocks  . 

Around  1970  researchers  began  to  invont  language  notations  for 
these  powerful  new  concopts. 
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VI..  LANGUAGE  OEVELQPmENT 

The  invention  of  precise  terminology  and  notation  plays  a 
major  role  not  only  in  the  sciences  but  in  all  creative 
endeavours. 

Uhen  a programming  concept  is  understood  informally  it  would 
seem  to  be  a trivial  matter  to  invent  a language  notation  for  it. 
3ut  in  practice  this  is  hard  to  do.  The  main  problem  is  to 
replace  an  intuitive,  vague  idea  with  a precise,  unambiguous 
definition  of  its  meaning  and  restrictions.  The  mathematician 
Polya  was  well  aware  of  this  difficulty  {^9^  t 

"An  important  step  in  solving  a problem  is  to  choose  the 
notation.  It  should  be  dona  carefully.  The  time  we  spend  now  on 
choosing  the  notation  may  well  bs  repaid  by  the  time  we  save  later 
by  avoiding  hesitation  and  confusion,  rfloraover,  choosing  the 
notation  carefully,  we  have  to  think  sharply  of  the  elements  of 
the  problem  which  must  be  denoted.  Thus,  choosing  a suitable 
notation  may  contribute  essentially  to  uncsrstanding  the  problem,” 
A prcgramraing  language  concept  must  represent  a ceneral  idea 
that  is  used  very  often,  Ctherwiss,  it  will  just  increase  the 
complexity  of  the  language  at  no  apparent  gain.  The  meaning  and 
rulss  of  a programming  language  concept  must  be  precisely 
defined.  Otherwise,  the  concept  is  meaningless  to  a programmer. 

The  concept  must  be  reprssented  by  a concise  notation  that  makes 
it  easy  to  recognize  the  elements  of  the  concept  and  their 
relationships.  Finally,  it  should  be  passible  by  simple 
techniques  to  obtain  a secure,  efficient  implementation  of  the 
concept.  The  compiler  should  be  able  to  check  that  the  rules 
governing  the  use  of  the  concept  are  satisfied,  and  the 
programmer  should  bs  able  to  predict  the  speed  and  size  of  any 
program  that  uses  the  concept  by  means  of  performance  measurements 
of  its  implsfijpntation. 
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As  long  as  nobody  studies  your  programs  their  readability  may 
not  seem  to  be  much  of  a problem.  But  as  soon  as  you  writs  a 
description  for  a wider  audience  the  usefulness  of  notation  that 
suppresses  irrelevant  detail  immediately  becomes  obvious.  So, 
although  Oijkstra's  THE  system  was  implemented  in  assembly 
language,  ha  found  it  helpful  to  invent  a language  notation  for 
concurrent  processes  in  his  descriptions  . 

The  following  example  of  Oijkstra’s  concurront  statement 
shows  two  sequential  statements  that  are  executed  simultanuously : 

yar  this,  next:  line 

cobegin  consume (this) j input(naxt)  coend 

While  one  statement  is  consuming  a line  of  text,  called  this, 
another  statement  is  inputting  the  next  line.  The  concurrent 
statement  terminates  whan  all  the  component  statements  are 
terminated. 

In  1971  Hears  pointed  out  that  the  concurrent  statement  only 
has  a predictable  effect  if  the  statements  within  it  operate  on 
different  variables  ^ll-Q.  In  this  example,  the  consumer  and  the 
input  statements  refer  to  different  variables  (this  and  next). 

If  the  programmer  by  mistake  lata  both  statements  refer  to  the 
same,  variable  the  effect  of  the  concutrant  statement  will  be 
time-dependent. 

To  prevent  time-dependent  programming  errors  a compiler  should 
be  able  to  recognize  the  private  variablss  of  a process  and  make 
them  inaccessible  to  other  processes.  Unfortunately,  this  is 
difficult  to  do  in  more  complicated  examples  involving 
procedures  and  global  variables.  The  solution  to  this  problem 
will  be  described  later. 

Although  it  is  essential  to  make  some  variablss  accessible  to 
one  process  only  it  is  also  necessary  to  enable  processes  to 
share  other  variables  to  make  cooperation  and  communication 
possible. 
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In  1971-72  notations  ware  proposed  for  associating  a shared 
variable  with  the  critical  regions  that  operate  on  it  ^10,  11^  • 
A shared  integer  used  as  a clock  is  a good  example! 

var  clock!  shared  integer 

ProcsGsas  can  either  increment  or  read  this  clock  by  statements 
of  the  form: 


tick!  region  clock  do  clock!=  (clock  -►  1 ) mod  max 

read(x) ! region  clock  do  X!s  clock 

The  compiler  checks  that  a shared  variable  is  accessed  only 
within  critical  regions.  The  computer  guarantees  that  these 
regions  are  executed  one  at  a time  without  overlapping, 

Hoara  also  invented  the  beautiful  concept  of  a conditional 
critical  region  which  is  delayed  until  a shared  variable 
satisfies  some  condition  (defined  by  a boolean  expression), 

A good  example  is  a message  buffer  consisting  of  a single  line 
slot  and  a boolean  indicating  whether  or  not  it  is  full ; 


var  buffer:  shared-  record 

slot  I line 
full:  boolean 
end 


The  sand  operation  is  a conditional  critical  region  that  is 
executed  when  the  buffer  is  empty: 


3end(m) : region  buffer  when  ^gt  full  ^ 
begin  slot  is  mj  full!s  true  end 

The  receive  operation  is  similar: 


recaiva(m)i  region  buffer  when  full  ^ 

begin  mis  slot;  fullis  false  end 


At  that  time  it  did  not  seem  possible  to  implement  conditional 
critical  regions  efficiently  on  a single  processor.  The  proolem 
was  to  limit  the  repeated  evaluation  of  boolean  expressions  until 
they  become  true.  As  a compromise  between  elegance  and  efficiency 
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procB33  queuBS  (also  called  "avedts”  or  "conditions'*)  associated 
with  shared  variables  were  proposed  [llj  . 

At  that  time  Dijkstra  auggesteo  that  the  meaning  of  process 
interactions  could  be  further  clarified  by  combining  all 
operations  on  a shared  data  structure  into  a single  program 
module  (instead  of  scattering  them  throughout  the  programtext)  , 
In  1973  a language  notation  for  this  monitor  concept  was 
proposed  ^123,  The  data  representation  of  a message  buffer 
together  with  the  sand  and  receive  operations  on  it  now  looked 
like  ^this : 

monitor  buffer 

slot:  line?  full:  boolean 

procedure  sard(m:  line) 

when  not  full  ^ 

begin  siot:=  mj  full!=  true  end 

procedure  rec3iue(var  m:  line) 
cghen  full  do 

' begin  rats  slotj  fullts  false  end 

begin  fullts  false  end 

The  monitor  includes  an  initial  statement  that  makes  the  buffer 
empty  to  begin  with.  In  a later  paper  Hoars  also  described  the 
monitor  concept  and  illustrated  it  with  examples  ["iS^, 

A central  theme  in  this  development  was  an  attempt  to  replace 
earlier  hardware  protection  mechanisms  by  compilation  checks. 

The  monitor  concept  enables  a ccmpiler  to  check  that  send  and 
receive  are  the  only  operations  performed  on  a message  buffer. 

Once  the  buffer  monitor  has  been  tested  systematically  the 
compiler  prevents  other  program  modules  from  using  it 
incorrectly.  This  tends  to  localizs  errors  in  new,  untested 
modules  and  prevent  them  from  causing  obscure  effects  in  old, 
tested  modules. 
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The  elimination  of  execution  checks  uias  not  done  just  to  maka 
compiled  programs  more  aff xciant.  In  program  engineering, 
compilation  and  execution  checks  play  the  same  roles  as 
preventive  maintenance  and  flight  recorders  do  in  aviation.  The 
latter  only  tell  you  ahy  a system  crashed?  the  formsr  prevents 
it.  This  distinction  is  essential  in  real-time  systems  that 
control  vital  functions  in  society.  Such  systems  must  be  highly 
reliable  before  they  are  put  into  operation. 

The  monitor  concept  solved  the  problem  of  controlled  access 
to  s.^'^.red  variables.  The  earlier  .problem  cf  controlling  the 
the  access  to  private  variables  i;;as  solved  by  declaring  each 
process  and  its  local  variables  a separata  program  module; 


process  producar 
var  next;  line 


cycle  input(nsxt)j  buf f ar.sQnd(next) 'end 


procGJ^s  consumgr 


var  this:  line 

cycle  buf far ,r3csiva(this} { consumeCthis)  and 


This  language  notation  makes  it  obvious  to  tha  program  readar 
and  tha  compiler  that  tha  variable  next  only  can  be  used  aithin 
tha  producer  process, 

Tho  first  programming  language  based  on  prccasses  and  monitor 
mas  Copcurrant  Pascal,  It  mas  defined  and  implsmsnted  in  1974 
^14^.  3y  the  and  of  1975  Concurrent  Pascal  had  bsen  used  to 
orita  three  minicomputer  operating  systems  of  600  - 14CQ  linas 
each,  Tha  development  and  documentation  effort  of  each  system 
mas  only  a fata  maeks  ^15  - isj,  A later  language  Wodula  (1977) 
is  also  based  on  the  process  and  monitor  concepts  [_17j  , 

These  language  concepts  had  a dramatic  impact  on  tha 
structure  of  concurrent  programs.  It  ncui  became  natural  to  build 
a concurrent  program  out  of  modules  of  one  page  each.  Since  each 
module  defines  all  the  meaningful  eperatiens  on  a singls  data 
structure  (private  or  shared),  tha  modules  can  be  studied  and 
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tasted  one  at  a tine.  As  a result  these  concurrent  programs 
became  more  reliable  than  the  hardware  they  ran  on.  And  their 
simplicity  made  it  possible  to  publish  the  entire  text  of  a 
concurrent  program  of  1300  lines  j^is]. 

It  is  interesting  that  sequential  programmers  independently 
mere  lad  to  the  discovery  of  program  modules  which  combine  data 
representations  and  procedures  into  units  ["is]  . But  although 
the  two  developments  lad  to  the  same  conclusions  the  motivations 
were  different:  concurrent  programmers  were  gradually  led  to 
modularity  simply  by  their  desire  to  master  synchronization  and 
prevent  racing  conditions.  These  problems  do  not  occur  in 
sequential  programs.  Sequential  programmers  were  motivated  by 
mora  abstract  concerns  for  clarity  and  the  desire  to  make 
program  verification  simpler, 

UII,  FORffTAL  UWDERSTANOING 

Cnee  you  have  a notation  far  a concept  it  becomes  possibls  to 
refine  it  further  and  get  a more  formal  understanding  of  its 
properties.  The  impact  of  notation  on  discovery  has  been 
Bxprassed  very  aell  by  Susanne  Langer  [_1sJ  » 

"There  is  something  uncanny  about  the  power  of  a happily  chosen 
ideographic  language;  for  it  often  allows  one  to  express  relations 
which  have  no  names  in  natural  language  and  therefore  have  never 
been  noticed  by  anyone.  Symbolism,  than,  becomes  an  organ  of 
discovery  rather  than  mere  notation," 

It  is  no  coincidence  therefore  that  tho  development  of  language 
notation  for  concurrent  programming  immediately  inspired 
theoretical  work  on  program  verification,  Hoare's  first  paper 
on  concurrent  programming  (l972)  contains  axiomatic  definitions 
of  the  meaning  of  concurrent  statements  and  critical  regions,  A 
later  paoer  by  Hears  (1974)  defines  the  effect  of  cusue  manipulatio 
within  monitors.  The  development  of  verification  rules  for 
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concurrent  programs  with  conditional  critical  regions  was 
carried  further  by  Quiicki  and  Cries  ^2o]  , 

It  remains  to  be  seen  what  affect  these  theories  will  have 
on  language  refinoment  and  program  reliability,  most  researchers 
would  agree  that  our  thooratical  understanding  of  concurrency  is 
still  in  its  infancy,  A successful  approach  in  this  area  will 
almost  certainly  require  that  computer  scientists  go  beyond 
well-understood  exorcises  and  concern  themselves  with  modal 
systems  of  a non-trivial  size, 

VIII.  HARDWARE  REFINEWENT 

The  trend  of  decreasing  hardware  costs  and  increasing  software 
costs  is  likely  to  continue  duo  to  batter  production  methods  and 
continued  inflation.  At  the  moment  the  use  of  abstract  prcgramminn 
languages  is  the  only  effective  way  of  reducing  software  costs. 
Unfortunately,  present  computer  architectures  do  not  support 
abstract  languages  efficiontly  compared  to  machine  language.  A 
real-time  programmer  is  therefore  faced  with  a meaningless  choice 
between  cost,  reliability,  and  efficiency.  The  solution  is  quite 
obvious:  we  must  build  computer  architectures  that  support  our 
programming  concepts  directly, 

A few  years  after  the  invention  of  the  block  and  procedure 
concepts  of  AlgoieO  the  first  stack  computers  appeared.  It  did, 
however,  taka  more  than  a decade  for  this  idea  to  be  generally 
adopted  by  most  computer  manufacturers, 

A similar  development  is  now  taking  place  in  concurrent 
prcgraroming , The  microprocessor  technolcgy  makes’  it  possible  to 
build  computer  architectures  that  will  support  the  process  and 
mcnitor  concepts  dirsctly,  A rscsnt  proposal  envisions  a computer 
with  10  microprocessors.  Each  processor  has  a local  store  dsdicatad 
to  a single  process.  The  processors  share  a common  store  that 
contains  the  mcnitoro.  This  computer  has  no  interrupts  and  doss 
not  multiplex  its  processors  among  several  processes  ^21^, 
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I mould  expect  an  increasing  number  of  computer  architectures 
to  be  oriented  towards  the  support  of  concurrent  programming 
languages  for  real-time  applications. 

For  applications  that  are  of  interest  to  a large  number  of 
people  it  mill  be  economical  to  specialiro  the  hardware  even 
further.  In  those  cases  it  seems  very  attractive  to  write  a 
concurrent  program  in  an  abstract  language  that  hides  machine 
detailf  test  it  on  an  existing  machine,  and  then  derive  the  most 
straight-forward  specialized  architecture  from  the  program  itself, 
LilJj  the  development  of  our  theoretical  understanding  the 
design  of  new  computer  architectures  for  concurrent  programming 
has  just  started  and  will  probably  continue  for  another  decade. 


IX,  THE  NEXT  CHALLENGE  i COmPLTER  NETWORKS 

It  has  taken  twenty  years  to  design  reliable  computer  systems 
in  which  concurrent  processes  share  storage.  And  now  hardware 
technology  has  provided  another  challenge:  microcomputer  networks 
in  which  processors  communicate  by  input/output  only  (without  any 
common  storags).  This  seems  a natural  approach  to  real-time 
applications  in  which  geographically  distributed  functions  must 
be  coordinated. 

Anyone  mho  took  the  word  'abstraction'  to  mean  'macnine 
independent'  suddenly  discovered  that  abstract  programming 
languages  merely  hide  the  irrelevant  differences  between  similar 
computer  architectures.  The  procedure  concept  is  still  fundamentally 
tied  to  the  existence  of  a common  store  for  parameter  passing.  And 
the  people  who  developed  monitors  for  concurrent  programming  also 
took  this  technological  assumption  for  granted. 

Mow  it  may  seem  that  the  solution  to  the  distributed  processing 
problem  is  simple:  message  passing  between  processors  connected 
by  cables  is  all  that  is  needed.  And  message  passing  (one  of  the 
oldest  ideas  in  concurrant  programming)  wo  surely  undorstand  very 
well.  Unfortunately,  it  is  not  that  easy. 
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What  uie  do  understand  is  deterministic  wessaaa  passing  in  which 
a receiving  process  waits  until  another  process  sends  a message 
on  a given  line.  In  such  a system  each  process  performs  a 
complotoly  predictable  transformation  of  its  input  to  its 
output.  The  analysis  of  individual  processes  must  be  supplied 
with  a global  analysis  of  termination  (or  absence  of  deadloclcs). 
This  can  be  guaranteed  by  a hierarchical  ordering  of  processes 
into  'masters’  and  'servants', 

A '^Tcent  paper  by  Hoars,  however,  makes  it  clear  that  one 
must  also  include  nondeterminist:.c  message  oassino  - a far  mere 
complex  problem  ^22j  , An  obvious  example  is  a process  that 
functions  as  a buffer  between  two  other  processes.  The  buffer 
process  cannot  predict  whether  its  environment  will  ask  it  to 
receive  or  send  a message  next.  Consequently,  it  cannot  commit 
itself  to  waiting  until  it  receives  a message  on  the  input  line, 
for  this  would  make  it  unable  to  respond  to  a request  for 
sending  a message  on  its  output  line.  Conversely,  it  cannot 
commit  itself  to  wait  until  it  is  asked  to  send  a message  either. 
For  this  would  make  it  unable  to  receive  further  messages  in  the 
meantime  thereby  slowing  down  the  producer  process  unnecessarily. 

What  is  needed  therefore  is  the  ability  of  a prccsss  to  delay 
itself  until  it  receives  either  a request  for  sending  or  receiving. 
It  must  then  be  able  to  perform  one  of  two  actions  depending  on 
what  is  was  asked  to  do. 

The  problem  is  further  complicated  by  the  finite  storage 
capacity  cf  a buffer  process.  When  the  buffer  is  full,  the 
prccess  cannot  accept  further  input;  and  whan  it  is  empty,  the 
process  cannet  deliver  further  output.  Hears  is  thersfors  Isd  to 
introducing  a non-datarministic  statement  cf  the  form: 
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when 

not  full ( buff ar) » input(x):  put(x,  buffer) 

not  enipty(buf far) , output  (x):  get(x,  buffer) 
end 

These  communicatino  sequential  processes  seem  somewhat 
inconvenient  for  the  programming  of  procosses  that  schedule 
other  processes.  To  handle  this  problem  the  concept  of 
distributed  orccesses  has  been  proposed  . It  combines  the 
proc;’ss  and  monitor  concepts  and  enables  one  process  to  call  a 
procedure  within  another  procsss  when  the  latter  process  is  waiting 
for  some  condition  to  be  satisfied  by  its  own  variables.  The 
parameter  passing  bstwesn  processes  can  be  done  by  a single  incut 
operation  before  a process  interaction  followed  by  a single  output 
oporation  afterwards. 

The  practicality  of  these  recent  proposals  have  not  yet  been 
established.  They  have  not  even  been  implemented  and  are  not 
understood  formally.  Their  main  value  is  to  make  it  clear  that 
distributed  computing  will  require  nsa  concepts. 

If  the  history  of  concurrent  programming  is  about  to  repeat 
itself  we  should  expect  the  new  hardware  challencs  to  lead  to  a 
software  crisis  as  the  technology  is  being  used  in  real-time 
applications  by  means  of  ad  hoc  programming  techniques.  The 
search  for  concepts,  languages,  and  theory  will  then  start  again. 
This  will  taka  longer  than  we  may  think,  I would  expect 
distributed  computing  to  be  reasonably  well  understood  by  the 
year  2QG0. 
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